1. Field of the Invention
This invention relates to communication systems and, more particularly, to communications occurring on the Internet or World Wide Web. The invention finds particular use in applications and services involving shopping and purchase of goods and services requiring payments of money.
2. Description of the Related Art
Many applications and services on the Internet, such as on-line shopping at an Internet shopping mall, depend on the purchaser's ability to pay for merchandise and services. Moreover, the appeal of electronic commerce without electronic payment is limited.
iKP (denoting 1KP, 2KP, and 3KP) is a family of secure electronic payment protocols for implementing credit card-based transactions between a customer and a merchant, while using the existing financial network for clearing and authorization (see M. Bellare et al., "iKP--A Family of Secure Electronic Payment Protocols," Proceedings of the First USENIX Workshop on Electronic Commerce, New York, N.Y., Jul. 11-12, 1995, pages 89-106, incorporated herein by reference). The iKP protocols are based on public key cryptography and are the forerunner to the Secure Electronic Transaction (SET) protocol (to be described next), a well-known protocol in widespread use today.
The Secure Electronic Transaction (SET) protocol was developed jointly by MasterCard and VISA and is described at http://www.mastercard.com/set/, incorporated herein by reference. SET was specifically designed to support payments based on the existing credit card infrastructure. SET uses a system of locks and keys along with certified account IDs for both consumers and merchants. Through a unique process of encrypting or scrambling, the information exchanged between the shopper and the on-line store, SET ensures a payment process that is convenient, private, and secure. Specifically, SET keeps payment information confidential, it increases integrity for all transmitted data through encryption, it provides authentication that a cardholder is a legitimate user of a branded payment card account, and it provides authentication that a merchant can accept branded payment card transactions through its relationship with an acquiring institution. Because the SET protocol is designed to support payments based on the existing credit card infrastructure and mechanisms, SET payments involve a substantial per-transaction fee (typically 20 cents minimum) and therefore are inappropriate for payments of small amounts.
Herzberg and Yochai describe a payment mechanism for small amounts, or "micro payments", which they call MiniPay, see Amir Herzberg and Hilik Yochai, "Mini-Pay: Charging per Click on the Web," Sixth WWW Conference, Santa Clara, April, 1997. The conference paper is also available on the Internet at http://www6.nttlabs.com/HyperNews/get/PAPER99.html, incorporated herein by reference. MiniPay is suitable for applications and services requiring the payment of small amounts, such as for information, games, and loadable software. The single item purchased via MiniPay could be a license to access a complete site for a predefined period of time. Consequently, once the buyer has acquired access to a site, he or she might then have free access to several additional HTML links available through that site. The parameters contained in the offer sent in an HTML page from the seller to the buyer would spell out the details of the offer. The MiniPay protocol is designed specifically to provide a means for payments of information or services purchased and delivered to a buyer over the Internet.
In a MiniPay protocol, a user of the Internet makes a small payment for a product or service, e.g., to receive an electronic stored copy of a a document such as a newspaper. A mini-payment is a small payment, e.g., a payment that does not exceed $25. In the case of a web document, before paying and seeing the actual document, the user may see--at no charge--an abstract, overview, or sales promotion that describes it. Before "seeing" the actual document, the user must issue a payment, which is accomplished by "signing", or preparing an electronic digital signature with the user's private key. Each user has a public/private key pair that can be used for authorizing mini-payments. In effect, the digital signature authorizes the payment. Once the signature has been prepared and verified, the user is then allowed to "see" the requested information. The MiniPay protocol is embedded in a "point and click" model that is designed to make access to electronically stored information as easy and painless as possible. Thus, when a user "clicks"--requesting to "see" the information--the MiniPay protocol is invoked transparently so that the cryptographic processing details are hidden from the user.
A disadvantage of the MiniPay protocol is that the user must commit--by making a payment--before "seeing" the actual web document. Therefore, it would be desirable if the user had a option for finding out more about a requested web document before "clicking" to pay and "see" the document.